Look good! Needs some testing, and we can really only support this with EXPERIMENTAL_FEATURES since it's not in the spec yet?

OK, this turned into a pretty big rework!

There's now a --experimental-quick-close option (enabled by default if it's an anchor_outputs channel, which is EXPERIMENTAL_FEATURES only anyway) which means we send the tlv. If we send and receive, we quick-close.

On the way I found that our fee estimation for closing txs was not actually using the weight of the closing tx, but the final commitment tx. This is v. different for anchor_outputs!

@niftynei might want me to break off the first commits for this release?

I'm having some trouble testing this on regtest for the case where c-lightning is fundee, c-lightning keeps insisting on a range containing a single value (instead of a range) strictly below 1 sat/byte, so I can't get eclair to propose such a range...

Can you help me figure out how to configure c-lightning to use higher on-chain fee estimates? Is there a configuration I can set to hard-code feerates on regtest or something similar?

Note that it made me realize that I got something wrong in eclair: the node operator chooses a fee range when initiating shutdown. But if the remote peer rejects that fee range entirely (with a warning message + disconnect) eclair will just retry the same fee range on reconnection, and I didn't provide a hook for the node operator to send a closing_signed with a different fee range (once shutdown has been initiated, I've made it so the fee range is fixed). I need to change that.

This also highlights a difference in behavior between eclair and c-lightning where I'd like to have your feedback. In my opinion, it never makes sense when you're fundee to reject the funder's proposed fee range like c-lightning does. You're fundee so you're not paying that fee:

• if you think it's too high, then it's great for you as you're not paying it and it will confirm faster
• if you think it's too low, then choose the highest fee in the proposed range and just go with it, you can always CPFP it later if needed, but since you didn't initiate the shutdown it's likely your peer will take care of CPFP-ing it (they started shutdown, so they need these funds back on-chain more than you do). I agree that this second case is more arguable, by refusing that fee maybe the funder will propose a higher fee which is better for you, but you're kinda strong-arming your peer for something that he will pay 100%, so it's a bit unfair.

WDYT?

Totally right about upper fee should be infinite. But lower fee risks them blocking you by creating low-fee children. So we do need a lower bound.

Spec should note this! I'll come up with some language

I'm having some trouble testing this on regtest for the case where c-lightning is fundee, c-lightning keeps insisting on a range containing a single value (instead of a range) strictly below 1 sat/byte, so I can't get eclair to propose such a range...

Can you help me figure out how to configure c-lightning to use higher on-chain fee estimates? Is there a configuration I can set to hard-code feerates on regtest or something similar?

In our test suite we pretend to be bitcoind and feed fake fees that way, but you're right, we should just include an option for regtest fees. I'll add a feature request.

Note that it made me realize that I got something wrong in eclair: the node operator chooses a fee range when initiating shutdown. But if the remote peer rejects that fee range entirely (with a warning message + disconnect) eclair will just retry the same fee range on reconnection, and I didn't provide a hook for the node operator to send a closing_signed with a different fee range (once shutdown has been initiated, I've made it so the fee range is fixed). I need to change that.

This also highlights a difference in behavior between eclair and c-lightning where I'd like to have your feedback. In my opinion, it never makes sense when you're fundee to reject the funder's proposed fee range like c-lightning does. You're fundee so you're not paying that fee:

* if you think it's too high, then it's great for you as you're not paying it and it will confirm faster

* if you think it's too low, then choose the highest fee in the proposed range and just go with it, you can always CPFP it later if needed, but since you didn't initiate the shutdown it's likely your peer will take care of CPFP-ing it (they started shutdown, so they need these funds back on-chain more than you do). I agree that this second case is more arguable, by refusing that fee maybe the funder will propose a higher fee which is better for you, but you're kinda strong-arming your peer for something that he will pay 100%, so it's a bit unfair.

OK, I've fixed this so we allow infinite max if we're non-funder. We still require estimatefee 100 as a min though; could possibly drop it below that, but not to the relay minimum I think.

WDYT?

Thanks, I ran more tests with 71cf497 and here is what I found:

• When eclair is funder:
  • c-lightning now correctly accepts my higher-than-expected fee
  • but eclair isn't happy with max_fee_satoshis = 0xffffffffffffffff because this is actually an invalid value for a satoshi amount since it's bigger than 21 million BTC...since c-lightning is simply accepting a value inside eclair's proposed fee range, I don't think it's necessary to set this to 0xffffffffffffffff (and I think our internal check here makes sense)
• When c-lightning is funder:
  • c-lightning sent fee_satoshis = 138 and fee_range = [138, 685]
  • eclair answered with fee_satoshis = 138 and fee_range = [138, 138] and published the closing tx
  • c-lightning sent another closing_signed (duplicate of the first one): it's harmless, but c-lightning shouldn't send that 3rd message, it should publish the closing tx (or not do anything if it has already seen it in the mempool)

Note that when we're fundee and accept a fee from the funder's proposed fee range, I chose to answer with a fee range containing only that fee (in the example above [138, 138]) since we both agree on it. Let me know if you think that could cause internal issues for c-lightning (the fundee could instead choose to send back the same fee range it received from the funder, I'm not sure which makes more sense).

OK, I'll fix the range to match (as the spec suggests, I was lazy!)

I'll check the c-lightning-as-funder case using lnprototest, which will catch this weirdness immediately. Thanks!

I have tested cross-compatibility between c-lightning 574f2b2 and eclair ACINQ/eclair@c37a2ca and everything looks good, thanks!

I have tested cross-compatibility between c-lightning 574f2b2 and eclair ACINQ/eclair@c37a2ca and everything looks good, thanks!

Thankyou! Beers are owed. Given the number of beers I now owe you, I suspect we're going to have to catch up for several weeks somewhere! :)

Beers are owed. Given the number of beers I now owe you, I suspect we're going to have to catch up for several weeks somewhere! :)

I'm down for that, it sounds like a very good plan, beers are owed both ways for everything you've done as well ;)

I need to create a fake account to Ack my PRs ;)

Ack 8a9e7e0